NitroROM File System Specifications

Note that this document has been reworded in an attempt to circumvent possible watermarking measures. No pertinent information has been lost.

Introduction

This document describes a simple file system which can be used to speed up development time, and where the program and data files map into ROM. Application developers need not concern themselves with the format of the file system; an API is provided.

Details within this document may change before final release.

Data Format

A NitroROM file has the following constituents.

For each block in the file, the developer can specify whether and to what granularity the block should be aligned. If alignment is required, padding will be added.

The ROM header is fixed at the top of the NitroROM file; all other blocks are accessed by direct or indirect pointers relative to the top of the header. Due to this, it is possible for the other blocks to lie in any order in the file.

ROM Header Format

The following table shows the format of the ROM_Header structure.

OffsetSizeTypeNameUse
000h8 bytesu8[]corp_idShould be "NINTENDO" *Reserved for system*
008h24 bytesu8[]reserved_AUnused, should be 0
020h4 bytesvoid*main_rom_offsetOffset of ARM9 startup code in ROM *Static module params*
024h4 bytesvoid*main_entry_addressEntry address [unimplemented]
028h4 bytesvoid*main_ram_addressARM9 destination RAM address
02Ch4 bytesu32main_sizeSize to copy for ARM9 code
030h4 bytesvoid*sub_rom_offsetOffset of ARM7 startup code in ROM
034h4 bytesvoid*sub_entry_addressEntry address [unimplemented]
038h4 bytesvoid*sub_ram_addressARM7 destination RAM address
03Ch4 bytesu32sub_sizeSize to copy for ARM7 code
040h4 bytesROM_FNTDir*fnt_offsetOffset of name table in ROM *Nametable params*
044h4 bytesu32fnt_sizeSize of table
048h4 bytesROM_FAT*fat_offsetOffset of allocation table *FAT params*
04Ch4 bytesu32fat_sizeTable size
050h4 bytesROM_OVT*main_ovt_offsetARM9 overlay offset in ROM *Overlay header params*
054h4 bytesu32main_ovt_sizeSize of ARM9 overlay
058h4 bytesROM_OVT*sub_ovt_offsetARM7 overlay offset
05Ch4 bytesu32sub_ovt_sizeSize of ARM7 overlay
060h16 bytesu8[]reserved_BShould be 0 *Reserved*
070h3984 bytesu8[]reserved_CAgain with the 0's
100h12288 bytesu8[]reserved_DAnd again

Startup Module

This is a supplied binary, linked in with the application ELF. The binary is placed in ROM without modification. The top ROM address for both processors must be aligned at a 512 byte boundary.

File Name Table

This table associates file names with IDs. The table is built up from two sub-tables: a table of directories, and a file table. Directories are distinguished from files by their ID: a file can only have an ID in the range of 0x0000-0xEFFF, and a directory has an ID of 0xF000-0xFFFF. Therefore, there can be a maximum of 61440 files and 4096 directories. Directory sub-table

The size of the directory table implies the number of entries within it; the subscript of a given entry corresponds to a directory ID of subscript+0xF000.

The following table specifies the format of the ROM_FNTDir structure.

OffsetSizeTypeNameUse
000h4 bytesu32entry_startOffset of the constituent file sub-table
004h2 bytesu16entry_file_idID of first file in the file sub-table
006h2 bytesu16parent_idID of parent directory

The directory with ID 0xF000 is the root directory. In this case, the parent_id field holds the number of directories contained within the filesystem, since it has no parent. File sub-table

An entry in a file sub-table can be produced with either of two structures; one describes a file entry, and one a directory reference. The developer must choose which structure to use dependent on the circumstances.

The following table describes a ROM_FNTStrFile entry.

OffsetSizeTypeNameUse
000hBitfield: 1 bitu8entry_type0 for a file
000hBitfield: 7 bitsu8entry_name_lengthLength of entry name
001h[length] byteschar[]entry_nameFile name (NOT zero terminated)

This table describes a ROM_FNTStrDir structure.

OffsetSizeTypeNameUse
000Bitfield: 1 bitu8entry_type1 for a dir
000Bitfield: 7 bitsu8entry_name_lengthLength of entry name
001[length] byteschar[]entry_nameDir name (NOT zero terminated)
[length]+11 byteu8dir_id_LDirectory sub-table ID, low byte
[length]+21 byteu8dir_id_HDirectory sub-table ID, high byte

A file or directory name must follow these rules:

Any file entries that are in the same directory are arranged in successive order, and as such get successive IDs. After a directory entry, and after the last file in a directory, a file entry of length 0 and name "\0" is entered.

Example filesystem:

Overlay Table Format

This table is normally created automatically by the compiler and linked in as binary. Since the IDs of the overlay files are not known at compile time, these must be filled in later.

The table comprises an array of ROM_OVT structures, which are described in detail below.

OffsetSizeTypeNameUse
000h4 bytesu32idOverlay ID
004h4 bytesvoid*ram_addressPoint at which to load
008h4 bytesu32ram_sizeAmount to load
00Ch4 bytesu32bss_sizeSize of BSS data region
010h4 bytesvoid*sinit_initStatic initialiser start address
014h4 bytesvoid*sinit_init_endStatic initialiser end address
018h4 bytesu32file_idOverlay file
01Ch4 bytesu32reservedFor future expansion

File Allocation Table

The FAT is made up of an array of ROM_FAT structures, which are given in detail below. The array subscript corresponds to the file ID given in the FNT. A set of zero values in a FAT entry designates an unused file ID.

OffsetSizeTypeNameUse
000h4 bytesvoid*topStart address of file in ROM
004h4 bytesvoid*bottomEnd address of file in ROM

File Images

The files are simply placed into the NitroROM image at the places specified by the FAT.